All committers have signed the CLA.

@navyadas-dev your PR says what you changed but not why that solves the problem or how to reproduce or test the problem. This is a public repo, so we need to show our work.

@navyadas-dev your PR says what you changed but not why that solves the problem or how to reproduce or test the problem. This is a public repo, so we need to show our work.

I had already added testing details in the ticket comments, and I’ve now included some additional information in the PR description as well. Please take another look when you get a chance, and let me know if anything else is missing or needs further clarification. Thank you!

Cross-posting from https://hashicorp.atlassian.net/browse/NMD-789?focusedCommentId=974394

I tried implementing the short-term solution for this issue

Issue:
When the user is on /clients or any page, the page can initiate multiple in-flight requests for node allocation data. Some of these requests may still be pending when the user navigates away from the page.

Cause:

Those requests are not always explicitly canceled when leaving /clients, so the browser can continue holding pending requests briefly after navigation starts.

Fix:
I added explicit watcher cancellation in deactivate() to ensure cleanup always happens when leaving the Clients page.
File Modified: ui/app/routes/clients/index.js

Testing Results

Network throttling: 3G
Browser: Chrome with DevTools open
Monitoring: Network tab + Console logs

BEFORE
Navigate to Clients page → wait 2-3 seconds → navigate to Jobs - 0.40ms to complete deactivation

AFTER
Navigate to Clients page → wait 2-3 seconds → navigate to Jobs - 0.30ms to complete deactivation

Observation: Minimal Difference
As the long-term solution involves backend changes to create the /v1/client-statuses endpoint, please let me know if there are any UI changes needed— happy to help with those.

BEFORE
Navigate to Clients page → wait 2-3 seconds → navigate to Jobs - 0.40ms to complete deactivation
AFTER
Navigate to Clients page → wait 2-3 seconds → navigate to Jobs - 0.30ms to complete deactivation

I'm not sure we've really reproduced the original problem here, have we? #25920 talks about deactivation but the Jira seems to suggest there's a user-visible problem, which sounds like a lot more than 0.4ms.

As the long-term solution involves backend changes to create the /v1/client-statuses endpoint,

You haven't explained this in the PR either, so I'll copy-paste from the Jira what this is referring to:

Long-term solution: We (additionally) build what we built for the jobs index page last year, a special /statuses endpoint, but for clients. This gives us a lighter-weight endpoint that we can possibly track multiple nodes on at once.

BEFORE
Navigate to Clients page → wait 2-3 seconds → navigate to Jobs - 0.40ms to complete deactivation
AFTER
Navigate to Clients page → wait 2-3 seconds → navigate to Jobs - 0.30ms to complete deactivation

I'm not sure we've really reproduced the original problem here, have we? #25920 talks about deactivation but the Jira seems to suggest there's a user-visible problem, which sounds like a lot more than 0.4ms.

As the long-term solution involves backend changes to create the /v1/client-statuses endpoint,

You haven't explained this in the PR either, so I'll copy-paste from the Jira what this is referring to:

Long-term solution: We (additionally) build what we built for the jobs index page last year, a special /statuses endpoint, but for clients. This gives us a lighter-weight endpoint that we can possibly track multiple nodes on at once.

This PR implements the short-term fix . As the long-term solution involves backend changes to create the /v1/client-statuses endpoint, please let me know if any UI changes are needed — happy to help with those.

@jrasell As discussed could you please help to provide a large data setup to validate this implementation in more detail? I’d like to test the behavior under heavier load conditions.